home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-181 < prev    next >
Text File  |  1988-12-01  |  13KB  |  525 lines
  1. To: Linda at ISIF
  2. Cc: JHaverty at BBNG
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.                                                           IEN-181
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.                    Van Gateway:  Some Routing
  30.                      and Performance Issues
  31.  
  32.                           Jack Haverty
  33.  
  34.                   Bolt Beranek and Newman Inc.
  35.  
  36.                             May 1981
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63. IEN-181                              Bolt Beranek and Newman Inc.
  64.                                                      Jack Haverty
  65.  
  66.  
  67.  
  68.      The  VAN  gateway  is  a  new   facility   currently   under
  69.  
  70. development  for the internet community.  Its intended purpose is
  71.  
  72. to  allow  interconnection  of  the  ARPANET  and  therefore  the
  73.  
  74. Internet  with  Telenet,  but  it also introduces a new mechanism
  75.  
  76. whose failure or misuse can seriously affect the system.  The key
  77.  
  78. problem  with  use  of  the VAN gateway is to allow and encourage
  79.  
  80. using it for legitimate purposes, while preventing utilization by
  81.  
  82. unauthorized  users  or  as  a  result  of a software or hardware
  83.  
  84. failure in the networks involved.
  85.  
  86.  
  87.      There are two aspects to this problem.  The first control on
  88.  
  89. the  gateway  usage  must  be  to  assure  that the packets being
  90.  
  91. handled  are  legitimate,  in  that  they  are  associated   with
  92.  
  93. authorized  users.   This  is  a specific example of the need for
  94.  
  95. mechanisms  which  have  been  discussed  at  various  times   as
  96.  
  97. "restricted routing" mechanisms.
  98.  
  99.  
  100.      The second control problem is to assure that the gateway  is
  101.  
  102. being  used  as  intended, with a reasonable level of traffic for
  103.  
  104. the  function  being  performed.   Even  if  packets  are   being
  105.  
  106. processed  for  authorized  users,  it  is  possible for failures
  107.  
  108. within the routing system or host software, for example, to cause
  109.  
  110. packets  to  loop  endlessly.   Failures of the network protocols
  111.  
  112. could similarly cause duplicate packets to be sent needlessly.
  113.  
  114.  
  115.  
  116.  
  117.  
  118.                                -1-
  119.  
  120.  
  121. IEN-181                              Bolt Beranek and Newman Inc.
  122.                                                      Jack Haverty
  123.  
  124.  
  125.  
  126.      In both cases, the concern results from the  highly  visible
  127.  
  128. impact which use of Telenet incurs, since charges are computed on
  129.  
  130. a per-packet basis.  However, the same issues are inherent in the
  131.  
  132. Catenet  itself, in that misuse of the network consumes resources
  133.  
  134. which are then unavailable for legitimate use.  Thus the  problem
  135.  
  136. of  managing  use  of  the  gateway  is most critical for the VAN
  137.  
  138. gateway, but applies as well to all gateways, and in fact to  any
  139.  
  140. shared resource.
  141.  
  142.  
  143.      In the initial implementation of the VAN  gateway,  resource
  144.  
  145. management is being provided by use of tables which enumerate the
  146.  
  147. authorized users of the gateway.   These  users  are  simply  the
  148.  
  149. addresses of the hosts, both on the ARPANET (Catenet) side and on
  150.  
  151. the Telenet side, which will be acceptable as  valid  source  and
  152.  
  153. destination  addresses of packets which transit the gateway.  All
  154.  
  155. other  packets  which  are  received  by  the  gateway  will   be
  156.  
  157. discarded.
  158.  
  159.  
  160.      In the  internet  architecture,  the  Telenet  side  of  the
  161.  
  162. gateway  appears  as a single network to the internet mechanisms.
  163.  
  164. The gateway contains a table which maps artificial host addresses
  165.  
  166. on  that  network  into  real 14-digit Telenet/X.25 addresses, in
  167.  
  168. much the same way as other networks  convert  internet  addresses
  169.  
  170. into  addresses  for  their  particular  attached  network.  X.25
  171.  
  172. virtual circuits are only permitted between the gateway and  X.25
  173.  
  174.  
  175.  
  176.                                -2-
  177.  
  178.  
  179. IEN-181                              Bolt Beranek and Newman Inc.
  180.                                                      Jack Haverty
  181.  
  182.  
  183.  
  184. hosts   which  are  present  in  this  translation  table,  which
  185.  
  186. effectively defines the set of authorized gateway  users  in  the
  187.  
  188. X.25 community.
  189.  
  190.  
  191.      No similar table is necessary for translation  of  addresses
  192.  
  193. on  the  ARPANET  side  of the gateway, since this translation is
  194.  
  195. well defined by the internet protocol.   Without  any  additional
  196.  
  197. mechanisms,  this  would  permit  any ARPANET host to use the VAN
  198.  
  199. gateway.  In addition,  since  gateways  to  other  networks  are
  200.  
  201. simply  ARPANET  hosts, this would permit any host on the Catenet
  202.  
  203. to use the VAN gateway.
  204.  
  205.  
  206.      To restrict the user community of the VAN gateway, a  second
  207.  
  208. table  is provided, which enumerates all internet addresses which
  209.  
  210. are acceptable as sources or destinations on the ARPANET side  of
  211.  
  212. the  gateway.   Each  internet  datagram  which  arrives from the
  213.  
  214. ARPANET or Telenet is checked  to  assure  that  the  source  and
  215.  
  216. destination addresses in the internet header are listed in one of
  217.  
  218. the two tables which define the set of hosts which are  permitted
  219.  
  220. to use the VAN gateway.
  221.  
  222.  
  223.      The table entries will be set  up  directly  by  DARPA.   In
  224.  
  225. selecting  the  set  of  valid hosts, the reliability of the data
  226.  
  227. presented to the gateway should be considered.
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.                                -3-
  235.  
  236.  
  237. IEN-181                              Bolt Beranek and Newman Inc.
  238.                                                      Jack Haverty
  239.  
  240.  
  241.  
  242.      In  particular,  we  note  that  there  is   a   significant
  243.  
  244. difference  in  the  addresses  presented  at  the gateway in the
  245.  
  246. internet header of each packet.  If such an address is in fact on
  247.  
  248. the  ARPANET,  the  gateway  can verify it by comparison with the
  249.  
  250. address supplied by the IMP in the ARPANET leader of the  packet.
  251.  
  252. For packets sent to the ARPANET, one can similarly expect the IMP
  253.  
  254. subnet to deliver the packet to the host specified in the ARPANET
  255.  
  256. leader.
  257.  
  258.  
  259.      If the address of a packet handled  by  the  gateway  is  on
  260.  
  261. another   component   network  of  the  Catenet,  the  packet  is
  262.  
  263. necessarily handled through one or more gateways.   The  internet
  264.  
  265. structure  permits gateways to freely enter the system.  Gateways
  266.  
  267. are in general under the control of the organization  which  owns
  268.  
  269. them  and/or  the  attached  network.  Gateways in general do not
  270.  
  271. check the addresses in the internet headers of packets which they
  272.  
  273. process,  so  it  is  possible  for  malfunctioning  hardware  or
  274.  
  275. software to emit  packets  with  incorrect  addresses.   If  such
  276.  
  277. addresses  happen  to be present in the VAN gateway tables, these
  278.  
  279. packets will be processed by the VAN gateway.
  280.  
  281.  
  282.      The impact of this situation on the policy for allowing  use
  283.  
  284. of  the  VAN  gateway  is  that  hosts on networks other than the
  285.  
  286. ARPANET are to be considered somewhat less reliable in  terms  of
  287.  
  288. enforcement  of  the usage policy.  The mechanisms in the initial
  289.  
  290.  
  291.  
  292.                                -4-
  293.  
  294.  
  295. IEN-181                              Bolt Beranek and Newman Inc.
  296.                                                      Jack Haverty
  297.  
  298.  
  299.  
  300. VAN gateway implementation will provide some  degree  of  control
  301.  
  302. over  the  use of the gateway, but these mechanisms are not to be
  303.  
  304. considered appropriate or complete in the general sense, and they
  305.  
  306. are  not  proof  against failures.  These mechanisms are intended
  307.  
  308. only as an interim measure.
  309.  
  310.  
  311.      We suggest that further development  work  on  the  internet
  312.  
  313. gateway  system,  of which the VAN gateway is a component, should
  314.  
  315. address the problems of resource control at the  internet  system
  316.  
  317. level.  Any mechanism which restricts the usage of a gateway must
  318.  
  319. be designed in conjunction with other network mechanisms, such as
  320.  
  321. routing, flow control, load sharing, and error control.
  322.  
  323.  
  324.      As an example, we can consider a hypothetical  configuration
  325.  
  326. in  which  two  VAN  gateways  are connected to Telenet, one from
  327.  
  328. ARPANET, and the other from SATNET, to  support  traffic  between
  329.  
  330. Telenet  users  and  hosts  on  ARPANET  or  SATNET.   Only these
  331.  
  332. user/hosts would be listed in the VAN gateway tables.
  333.  
  334.  
  335.      Since the VAN gateways  are  participants  in  the  internet
  336.  
  337. routing  mechanisms,  failure  of the gateway between ARPANET and
  338.  
  339. SATNET would cause the  system  to  recognize  the  path  through
  340.  
  341. TELENET,  as  a  transit  network, as a viable route for ARPANET-
  342.  
  343. SATNET traffic.  However, this traffic would be discarded at  the
  344.  
  345. VAN gateway because the addresses are not listed in its tables.
  346.  
  347.  
  348.  
  349.  
  350.                                -5-
  351.  
  352.  
  353. IEN-181                              Bolt Beranek and Newman Inc.
  354.                                                      Jack Haverty
  355.  
  356.  
  357.  
  358.      This scenario will be avoided  by  preventing  the  two  VAN
  359.  
  360. gateways  from  being  "neighbors" for routing purposes, which is
  361.  
  362. acceptable  only  in  restricted  configurations.   The   general
  363.  
  364. problem  results  from the usage restrictions at the VAN gateway,
  365.  
  366. which makes the path a valid route for one class of packets,  but
  367.  
  368. invalid  for other classes.  The current routing mechanism cannot
  369.  
  370. handle this situation.
  371.  
  372.  
  373.      In addition, the effect of the usage restrictions on  future
  374.  
  375. mechanisms for handling partitioned networks, and load sharing of
  376.  
  377. gateway paths, must be investigated.
  378.  
  379.  
  380.      We have two  mechanisms  to  propose  for  consideration  as
  381.  
  382. mechanisms  to  attack  this  problem.   The  first is a resource
  383.  
  384. control model which is a result  of  the  TIP  Login  work.   The
  385.  
  386. second  involves the use of performance models, which monitor use
  387.  
  388. of resources to determine if unexpected behavior  occurs.   These
  389.  
  390. two  mechanisms can be introduced to work more effectively in the
  391.  
  392. VAN gateway problem.
  393.  
  394.  
  395.      The architecture for the TIP Login system identifies several
  396.  
  397. abstract modules which interact to implement the resource control
  398.  
  399. functions.  A  "Control  Point"  is  the  module  which  directly
  400.  
  401. controls  the use of a resource.  It is responsible for detecting
  402.  
  403. an attempt to use  some  resource,  collecting  such  information
  404.  
  405.  
  406.  
  407.  
  408.                                -6-
  409.  
  410.  
  411. IEN-181                              Bolt Beranek and Newman Inc.
  412.                                                      Jack Haverty
  413.  
  414.  
  415.  
  416. which  identifies who is trying to use the resource and what they
  417.  
  418. are trying to do, and then  permitting  or  denying  use  of  the
  419.  
  420. resource.   The  decision  concerning whether or not a particular
  421.  
  422. usage is allowed is made by  a  "Decision  Module."  This  module
  423.  
  424. takes  the information supplied by the Control Point, and applies
  425.  
  426. the  algorithm  which  defines   the   resource   usage   policy.
  427.  
  428. Typically,  and  particularly in the Tip Login case, the Decision
  429.  
  430. Module will obtain more information  about  the  particular  user
  431.  
  432. and/or  resource involved in the decision, by using a distributed
  433.  
  434. database system.
  435.  
  436.  
  437.      In the TIP Login system, the Control Point is at  each  TIP.
  438.  
  439. Decision  Modules  are  located  in  special-purpose  hosts.  The
  440.  
  441. database system is present in those hosts as well  as  on  larger
  442.  
  443. database-maintenance  hosts, where tools to manipulate and modify
  444.  
  445. the database exist.  Typically the Decision Module identifies the
  446.  
  447. particular  individual  attempting  to use a TIP, and retrieves a
  448.  
  449. record of information specific to that individual, which  defines
  450.  
  451. his authorizations (or lack thereof).
  452.  
  453.  
  454.      Much of this mechanism should prove to be useful as a  basis
  455.  
  456. for  control  of gateways as well.  In such a system, the control
  457.  
  458. points would be at the gateways.  Decision Modules might also  be
  459.  
  460. at  the  gateways,  if  decisions  must  be  made on each packet.
  461.  
  462. Decisions might be based on source or destination  addresses,  or
  463.  
  464.  
  465.  
  466.                                -7-
  467.  
  468.  
  469. IEN-181                              Bolt Beranek and Newman Inc.
  470.                                                      Jack Haverty
  471.  
  472.  
  473.  
  474. on the identify of the individual responsible for the packet.  We
  475.  
  476. suggest that this approach be considered for further research.
  477.  
  478.  
  479.      A problem which is not  being  addressed  currently  is  the
  480.  
  481. second  control  problem mentioned earlier, namely the monitoring
  482.  
  483. of the use of some resource by an authorized user,  to  guarantee
  484.  
  485. that  the resource is being used as intended.  In the VAN gateway
  486.  
  487. case,  for  example,  a  malfunctioning  TCP  might  cause   many
  488.  
  489. unnecessary  packets to be handled, but since they are associated
  490.  
  491. with authorized addresses, no control is applied.  In addition to
  492.  
  493. the  obvious  cost  and performance penalties, lack of monitoring
  494.  
  495. precludes  the  use  of  policies  which  grant  limited  use  of
  496.  
  497. resources  to,  for example, allow some users to handle only low-
  498.  
  499. throughput traffic, or low priority traffic.  We believe that the
  500.  
  501. use  of  performance models, embedded within the gateways and for
  502.  
  503. hosts, is a promising direction for attacking this problem.
  504.  
  505.  
  506.      Limitations of the current LSI-11 implementation of the  VAN
  507.  
  508. gateway  are  likely to preclude any significant testing of these
  509.  
  510. approaches.  We  have  been  pursuing  these  ideas  as  research
  511.  
  512. issues,  which  have  surfaced  during the current implementation
  513.  
  514. efforts.
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.                                -8-
  525.